1. Field of the Invention
The present invention relates to service oriented architecture (SOA) and more specifically to an abstract SOA repository.
2. Introduction
Service-Oriented Architecture (SOA) is becoming a popular architecture for managing various services offered through a computer environment. Most organizations such as businesses or the government provide services to customers, clients, citizens, employees, or partners. As an example, bank tellers provide services to bank customers. Different tellers may offer different services, and some tellers may be specifically trained to provide certain types of services to the customer, such as account management, car loans, withdrawals or deposits and so forth. Several tellers may offer the same set of services to provide load balancing and high availability. What happens behind the counter does not matter to the customer, as long as the service is completed. Processing a complex transaction may require the customer to visit several tellers and therefore implement a business process flow.
Behind the counter are the information technology (IT) systems that automate the bank's services. The services are provided to the customer via the tellers. The services implemented by the IT systems must match and support the services provided by the tellers. A consistent approach to defining services on the IT systems that align with business functions and processes makes it easier for the IT systems to support the goals of the business and adapt more easily to providing the same service through humans, ATMs, and over the Web.
The same service provided by the tellers can be accessed from customers at the ATM, tellers on the office network, or Web users from their PCs. The services are designed and deployed to match the services that customers need. The implementation environments for the services do not matter in that the service is the focus. Two services can easily be combined to create another service, such as how the withdrawal and deposit service are composed into a transfer service.
The definition of software services aligns with the business services that a bank offers to ensure smooth business operations and to help realize strategic goals such as providing ATM and Web access to banking services in addition to providing them in the branch office.
More complex applications can be composed from services, such as processing a purchase order or an insurance claim. Deploying services in the context of an SOA makes it easier to compose services into simple or complex applications, which can also be utilized as services that can be accessed by humans and IT systems alike.
A service-oriented architecture is a style of design that guides all aspects of creating and using business services from conception to retirement. An SOA is also a way to define and implement an IT infrastructure to allow different applications to exchange data and participate in business processes, regardless of the operating systems or programming languages underlying those applications.
An SOA can be thought of as an approach to building IT systems in which the organizing principles are the functional services that IT systems expose to each other, or more abstractly, that functional domains within the enterprise expose to other functional domains. In contrast, earlier approaches to building IT systems tended to replicate the same functionality across different interfaces either within the same system or across different systems. They also did not adopt a common interoperability strategy that would enable an exposed service to be reused by all other endpoints. One characterization of the result of the traditional way of developing IT systems is an “accidental architecture,” which is a gradual accretion of replicated system and application functionality interconnected with diverse middleware. An IT infrastructure that evolves into an accidental architecture misses the primary aim of architecture—which is to break down complicated problems into simple pieces and eliminate or reduce complexity to make construction and maintenance easy.
Businesses can obtain a competitive advantage by successfully implementing an SOA using a common interoperability strategy because there is more reuse of service functionality, less reinvention of the wheel and less need for testing, greater ability to compose solutions by aggregating existing services, and greater focus on and understanding of key enterprise services. These advantages enable them to react more quickly to changing business requirements than businesses who are still replicating service functionality on an as-needed basis, to the middleware and implementation preferences of the project de jour. These advantages also provide them with a better return on IT investments.
A common interoperability strategy work works across all execution environments within the enterprise is integral to successful SOA initiatives. It provides the ability to interconnect different execution environments, clearly separating the service interface from the execution technology, allowing IT departments to choose the best execution environment for each job and tying them together using a consistent architectural approach. Previous implementations of SOA were based on a single execution environment technology.
The idea of separating an interface from its implementation to create a software service definition has been well proven in J2EE, CORBA, COM, and DCE. But the ability to more cleanly and completely separate a service description from its execution environment is an additional feature of SOA. One way to do this is to compile implementation-agnostic interface description files into native interfaces by leveraging compilers developed for each native execution environment. Some highly interoperable technologies, such as Web Services are text based middlewares that lose performance in the conversion to binary execution environments. However, in many cases, the performance issue is less important than achieving interoperability. Other less universally interoperable technologies, such as CORBA, are binary middlewares that operate with very high performance. Typically, an interoperability strategy must support a number of middlewares to satisfy all use cases. Key is the ability for a service exposed according to the common interoperability strategy to be consumable by all endpoints within the enterprise. The greater separation of interface from execution environment in SOA facilitates the separation of work responsibilities as well. Separating the service function from its technology implementation means that businesses can think about and plan IT investments around the realization of operational business considerations, as represented by the service description, more so than the capabilities of any individual product or software technology chosen to execute the function. In this case, the service description becomes the definition of a reusable business function that all enterprise endpoints can consume.
The advantages of SOA are achievable if businesses stay focused on defining and developing reusable Concept-of-OneSM services. Concept-of-OneSM, in this context, means that service functionality is generalized so that there is one service for each function, rather than multiple variations of the same function spread across an ever expanding ser of services. An important early step toward realizing the advantages of SOA is to define a target services roadmap that carefully organizes and plans out enterprise services to be developed. This strategic exercise is necessary to ensure that high-quality general-purpose and highly reusable services will be created, as opposed to highly customized one-off services that serve the needs of one tactical project only. This roadmap will evolve over time, but it is necessary to guide the execution of tactical teams building functionality for specific projects. With the guidance of the target services roadmap, implementation teams operating in parallel will gradually build out the target vision over time.
A significant value of SOA comes at the later stages of deployment, when such a large base of target services have been implemented, that new applications can be developed entirely, or almost entirely, by composing existing services. When new applications can be assembled out of a collection of existing, reusable services, the best value for effort can be realized.
There are benefits of reusing common business services such as customer name lookup, zip code validation, or credit checking. All services are abstract units of functionality accessed via an API of some sort. There are many levels of SOA starting at the highest interfaces supporting customer interfaces to the lowest interfaces between components in a single system (e.g., between the device driver and the operating system). Basically, every interface between two layers or components can be regarding as a SOA interface where one layer or component exposes services to the other (e.g., the device driver exposes a services layer to the operating system so that the operating system doesn't have to deal with the hardware directly. Similarly each integrated circuit chip exposes an API to assembler code executing in that environment so that the assembler code doesn't have to deal directly with the complexity within the integrated circuit chip itself). In a scope that is limited to a single system, which is built entirely with Java, a Java class (e.g., an EJB) may be a good way to realize an abstract service interface. What makes an architecture service oriented is the focus on abstract services, and more specifically, general-purpose units of functionality that are reusable by all endpoints within the scope of that architecture, and not the choice of implementation technology.
Using services not only reduces the amount of deployed code, but it also reduces the management, maintenance, and support burden by centralizing the deployed code and managing access to it.
An important aspect to a successful SOA is determining the correct design and function of the services in the reusable service library, which reflects the functional behavior of the architectural scope that SOA is being applied to. At the highest levels of the enterprise, SOA focuses on service functionality serving operational business processes. The successful definition and implementation of those SOA services ensures that operational business processes can be changed quickly and easily as external environmental changes cause an organization to adapt and evolve.
Some challenges to adoption of SOA include ensuring adequate staff training, creation of the target services roadmap, governance of services that are being implemented, and monitoring, management and reporting on how implemented services are being reused and are achieving the target.
Another challenge is managing short-term costs. Where legacy systems are involved, moving to an SOA target service may require additional incremental investment beyond the traditional alternative of tweaking the legacy service. This incremental investment typically generates a substantial return over time. Building a repository that can express the abstract SOA target, while capturing the implemented services and mapping them to the target is also costly and complex and is part of the SOA infrastructure that must be deployed. Without the SOA repository, different development teams working on different projects will end up producing similar versions of the same functional services. This is typical of past practice before SOA and adds to development cost, complexity and on-going maintenance while reducing developer productivity and efficiency. Beyond the need to enter newly implemented services into the repository, another challenge is getting pre-existing services, built before the SOA program came into being, into the repository of implemented services. Like newly implemented services these services must also be mapped to the SOA target. One of the needs in the art is an improved SOA repository that is capable of defining an abstract SOA target and mapping new and existing services to it at both the service an operation levels.
Another challenge is that some applications may need to be modified in order to participate in the SOA, specifically; their interfaces may need to be upgraded to conform to the SOA interoperability standards defined for that part of the architecture.
With respect to the interoperability standards, an attempt should be made to standardize the enterprise middleware to the maximum extent possible. Multiple enterprise middlewares carry significant costs. For example, if the interoperability standards are unclear, the same interface may need to be redeveloped in different middlewares according to the preferences of different clients. Cost is required to version, patch and maintain each middleware stack at each endpoint. Bridges, adapters and tunnels may also be required to interoperate between middleware domains. While it is desirable to have a single enterprise middleware, prevailing use cases may require the enterprise to adopt different middlewares under clearly specified circumstances (e.g., when messages over 1 Megabyte must be sent, when 10 s of milliseconds is significant to middleware performance budgets or where transactional messaging must be used).
Web services usually satisfy the use cases presented by the majority of interfaces. With Web services, by compiling a WSDL interface description file to a native implementation using a Web Services toolkit. Toolkits are available for C/C++, CORBA, Java, Microsoft, MQ Series, TIBCO and other implementation environments. Due to the popularity and industry backing behind web services, packaged application vendors like Siebel and SAP often create their own Web Services interfaces. Web Services usually can't handle all the use cases presented by a complex enterprise and other technologies to complete the interoperability specification.
Many vendors have developed Universal Description, Discovery and Integration (UDDI) repositories which describe web service implementations, but SOA is a much broader concept than web services implementation technology alone. UDDI repositories do not distinguish between an abstract services target and a concrete service implementation. An abstract service may need to be implemented in multiple middlewares but UDDI repositories can only support Web Services. Other vendors have reuse repositories for arbitrary assets (e.g., software code or engineering documentation) but they are not designed to address the needs of a service oriented architecture repository either.
Accordingly, what is needed in the art to further assist and promote the implementation of SOA is an improved tool that enables one define an abstract services target, record a concrete service implementation, map the implemented service to the target, and support service definitions irrespective of the middleware technology that they may be implemented in. Furthermore, what is needed in the art is an improved way of monitoring, managing and reporting on SOA services.